Page History: Sequence Reset
Compare Page Revisions
Page Revision: 2012/09/06 10:52
Resetting Sequence NumbersThe Sequence Reset message requests a counterparty to expect a new sequence number than what is expected on the counterparty side. The new sequence number is indicated by the mandatory field NewSeqNo (Tag 36). Under out of sequence conditions, Sequence Reset messages are important as they provide a mechanism to skip message gaps that are not to be honored for a
Resend Request. Sequence Resets also provide a mechanism of recovery for disaster conditions.
Sequence numbers resets can only increase the sequence numbers. Sequence Resets attempting to reset to a sequence number less than expected can generate a
Resend Request condition or a
Session Reject condition.
Sequence Resets are encountered in two modes:
- Gap Fill Mode (Tag 123 - GapFillFlag=Y)
- Reset Mode (Tag 123 - GapFillFlag=N or absent)
Gap Fill ModeGap-Fill Sequence Resets attempt to fill the sequence number gap by indicating (with Tag 36) the sequence number of the message that shall be expected immediately following the skipped message gap.
Gap-Fill Sequence Resets are generated as a response to the
Resend Request message to indicate that messages are to be skipped from the requested resend range. Messages may be skippped in a resend sequence as the messages can be administrative (e.g. heartbeats, test requests, etc.) or the resending party opts not to send certain messages per risk and/or age considerations.
Message gaps where multiple messages are to be ignored should be serviced by a single Sequence Reset and not by one Sequence Reset per message. For instance, if a gap exists for sequence numbers 89 to 95, one single Sequence Reset with NewSeqNo (Tag 36) equals to 96 should be sent.
The Gap-fill mode Sequence Reset must conform to the protocol sequencing rules. Hence, the sequence number of the Gap-Fill message (as reflected in Tag 34) must reflect the next sequence number expected by the counter party. This next sequence number should represent the beginning of the message gap (i.e. the sequence number of the first message in the message gap). Failure to adhere to sequencing rule will result in a
Resend Request message.
Reset ModeThe Reset mode Sequence Reset is applicable to application failures where the traditional Gap-Mode Sequence Reset is not able to regain normal sequence progression. Reset Mode Sequence Resets should only be considered for disaster recovery situations.
The Reset mode Sequence Resets do not adhere to the protocol sequencing rule. Hence, a
Resend Request will not be generated for an incorrect sequence number (as reflected on Tag 34 of the Sequence Reset message). Please note, that the use of Reset Mode Sequence Resets carry the possibility of losing messages.
Recovery of Last ResortIf an application recovery with Sequence Resets is not achievable, dropping the physical connection will terminate the FIX Session. Upon reconnection, normal traffic operations will resume as a new T4 FIX API session will be started with sequence numbers set to 1. Please, note that the possibility of losing messages exist with this measure of last resort.
Message Dictionary| Tag | Field Name | Req'd | Comments |
|---|
| Standard Header | Y | MsgType = 4 |
| 123 | GapFillFlag | N | Indicates that the Sequence Reset message is replacing administrative or application messages which will not be resent. |
| 36 | NewSeqNo | Y | New sequence number |
| | Standard Trailer | Y |
Sample Message
Resetting Sequence Number to 30
34=2|49=test|56=T4Test|50=TraderName|52=20120906-14:14:16.424|36=30|123=Y|
[FIXSEQUENCERESET]
[MsgSeqNum] 34 = 2
[SenderCompID] 49 = test
[TargetCompID] 56 = T4Test
[SenderSubID] 50 = TraderName
[SendingTime] 52 = 20120906-14:14:16.424
[NewSeqNo] 36 = 30
[GapFillFlag] 123 = Y (YES)
FIX API Home Page.